ソフトウェアアーキテクチャの基礎 ―― エンジニアリングに基づく体系的アプローチ

https://www.oreilly.co.jp/books/9784873119823/

原著 : Fundamentals of software architecture : an engineering approach

著者 : Mark Richards、Neal Ford

訳 : 島田浩二

https://m.media-amazon.com/images/I/51d1HhG4tzL._SX389_BO1,204,203,200_.jpg

Amazon : https://amzn.to/3hZdOwH

はじめに : 公理を疑う

ソフトウェア開発のエコシステムは動的な平衡状態 : 均衡が保たれつつ、長期的には動的

1 章イントロダクション

ソフトウェアアーキテクトのキャリアパスが定まっていない

ソフトウェアアーキテクチャ自体の定義が曖昧だし、変化が激しい

ソフトウェアアーキテクトの役割が広範

プロセスに関する問題がソフトウェアアーキテクチャの領域に入ってきている (プロセスはアーキテクチャの多くの面に影響)

それでもプロセスとエンジニアリングプラクティスは分けて考えるべき

ソフトウェア開発における予測や見積りの難しさは、未知の未知に起因

『進化的アーキテクチャ ―― 絶え間ない変化を支える』では、アーキテクチャ適応度関数という考えを提案

DevOps はアーキテクチャの公理が見直されたことで登場

従来は運用を外部に委託していた会社が多く、アーキテクトが運用に対して防御的になっていた

運用上の能力をアーキテクチャ内部で扱えるように設計し、結果として複雑なアーキテクチャになっていた

近年は、アーキテクチャを運用と連携させ、設計を単純にし、運用メンバーに最適な対応を任せるように

アーキテクトと運用メンバーが組むことで、マイクロサービスが作られた

ソフトウェアアーキテクチャの法則

ソフトウェアアーキテクチャはトレードオフが全て

「どうやって」よりも「なぜ」の方がずっと重要

I 部基礎

2 章アーキテクチャ思考

アーキテクチャ思考

3 章モジュール性

モジュール

モジュール性を把握するのに役立つ 3 つの考え方

4 章アーキテクチャ特性

アーキテクトはドメインやビジネスの要件の定義に協力しつつ、アーキテクチャ特性の定義、発見、分析に責務を持つ

あらゆるアーキテクチャ特性を備えようとすると扱いにくい設計になってしまう

アーキテクチャをできるだけイテレーティブに設計すべき

5 章アーキテクチャ特性を明らかにする

アーキテクチャ特性を明らかにするのは、アーキテクチャ設計や既存アーキテクチャの正当性の判断のための最初の一歩

アーキテクチャ特性を明らかにするには、ドメインの関心を翻訳できる必要

ドメインのステークホルダーとアーキテクトの言葉の壁 → ドメインの関心事からアーキテクチャ特性への翻訳

アーキテクチャ・カタ

ユーザー数から、スケーラビリティや弾力性を考慮

カスタマイズ性もひとつのアーキテクチャ特性

暗黙的なアーキテクチャ特性 : 可用性、信頼性など

6 章アーキテクチャ特性の計測と統制

アーキテクチャ特性について客観的な定義を持つべき (組織内での会話が円滑になる)

アーキテクチャ特性の計測

アーキテクチャ特性の統制

7 章アーキテクチャ特性のスコープ

『進化的アーキテクチャ ―― 絶え間ない変化を支える』で定義されたアーキテクチャ量子の概念

コナーセンス

8 章コンポーネントベース思考

アーキテクトは、アーキテクチャを構成するコンポーネントを定義し、改良し、管理、統制する

コンポーネントは、アーキテクトが関わるソフトウェアシステム構成要素の中で (例外を除き) 最も小さいもの

アーキテクチャスタイルの重要な側面である最上位分割

技術による最上位分割 : レイヤードアーキテクチャなど

ドメインによる分割 : モジュラーモノリス、マイクロサービスアーキテクチャなど

『エリック・エヴァンスのドメイン駆動設計』に触発されている

エンティティの罠

モノリシックアーキテクチャと分散アーキテクチャ

II 部アーキテクチャスタイル

アーキテクチャスタイルとアーキテクチャパターン

9 章基礎

10 章～ 17 章

各アーキテクチャスタイルの説明

オーケストレーション駆動サービス指向アーキテクチャ

マイクロサービスアーキテクチャ

18 章適切なアーキテクチャスタイルを選ぶ

III 部テクニックとソフトスキル

19 章アーキテクチャ決定

アーキテクチャ決定が、アーキテクトに求められることのひとつ

アーキテクチャディシジョンレコード (アーキテクチャ決定記録文書)

20 章アーキテクチャ上のリスクを分析する

リスクマトリクス、リスクアセスメント、リスクストーミング

21 章アーキテクチャの図解やプレゼンテーション

本書の描画ツールは OmniGraffle (特定のツールを推奨しているわけではない)

標準ダイアグラム : Unified Modeling Language (UML)、C4 モデル図 (C4)、ArchiMate

プレゼンテーション

文書とは違い、発表側が時間をコントロールする

2 つの情報チャネルがある (スライドと話者) ので、それらをうまく使う

22 章効果的なチームにする

アーキテクトは、アーキテクチャを実装する際の制約 (= 箱) を作る

境界がきついとフラストレーションがたまり、ゆるいと混乱を招く

ブルックスの法則 (= プロセスロス)、多元的無知、責任の分散

チェックリストを活用する

設計指針を用いてガイダンスを提供

技術スタック

23 章交渉とリーダーシップのスキル

アーキテクトは多くの人から異議を唱えられる

開発チームからも、他のアーキテクトからも、ステークホルダーからも

交渉とファシリテーションの能力が重要

交渉でも分割統治が使える

常に正当な理由を示すこと

象牙の塔のアーキテクトアンチパターン

リーダーとしてのソフトウェアアーキテクト

24 章キャリアパスを開く

ソフトウェアアーキテクトのキャリアパスについて

20 分ルール

パーソナルレーダーの開発

テクノロジーレーダー

アーキテクトは技術のポートフォリオを金融のポートフォリオと同じように扱うべき

Build your own Rader ツール

#書籍 #文献